[Mojang] Tomas Alaeus

Sorry for not updating this ticket more, we've reached out here and there about what's going on with this issue but forgot this place.

Unfortunately the fix that was implemented for 1.1 didn't fix the issue, and the fix that got added in 1.2 made it even worse (which is why 1.2 was never released for Apple TV). There is no date on when there is a fix coming, but we have people working on rewriting the entire iCloud implementation to get it right.

We did screw up and we're really sorry for the inconvenience this has caused you. I will be watching this ticket and keep it updated with our progress and answering any questions you have.

@unknown: Well, if Android force closes the app because it doesn't respond within 10 seconds, then it is our fault for not making it respond fast enough. There is no reason why the app shouldn't respond in time, thus it's a valid bug that we definitely can fix.

Ok, I think I managed to solve the issue now. I don't know why the device had problems compiling the shader code, what caused it or which part of the shader compilation that failed (Motorola building the device, Nvidia building the chipset, X for making the compiler, Khronos group for defining GLSL). But I do know that if I have to continue investigate this issue then I will lose brain cells.

Details: It's actually not just NEON instructions that make the Xoom (Tegra 2) different from others. It's also that it doesn't support VFPv3 which is another optional instruction set available on ARMv7 processors. For the Android target which Google calls "armeabi-v7a" they only require Thumb2 and VFPv3-D16 (not VFPv3). Disabling NEON was therefore not enough, we also need to turn it down to VFPv3-D16.

In short: I think I have successfully built the game with only VFPv3-D16 (instead of VFPv3 and NEON) and it does seem to work on the Xoom that we have here. It also doesn't seem to affect performance negatively in any measurable way. Yay \o/.

Yay, it starts now. There were some other issues with shaders (which might fix the startup issue for others that have NEON devices) that I had to fix as well. I need to tweak it, clean it up and measure the performance hit as well.

I've seen that page. Unfortunately it doesn't really help. I'm currently battling our build system/compilers to get them to build the game without NEON instructions. Depending on how the game performs after that there will be some different routes that we can take.

If you want to clear all chunks you could just teleport the player somewhere else and send new chunks as usual.

Ah, now I understand the issue better.

Right now it could be considered a third party bug. But we do want third party servers to exist, and the packet is supposed to (at the moment) replace an entire chunk. This bug causes a chunk to not be replaced completely in some cases.

No, but probably later.

edit: If there is a bug that is. I still haven't tried to reproduce it. I haven't heard that this is an actual problem from other server developers.

I didn't fully understand the issue. Are you sending a FullChunk packet (id 58), but the client doesn't rebuild previously empty subchunks?

(for what it matters, I consider this a real bug in the client, because we do want to support third-party servers doing stuff like that)

Should be fixed in the "next" version.

Hilarious bug. 😃
Should be fixed in the next version.

It should be fixed in the next release, sorry for the delay.

Added a more detailed description of the actual bug.

The Redstone tick issue impacts a variety of machines that people may want to build.

Yes, we know this.

All I want is a room that can't be broken into. I've stretched the limits of my creativity getting this far. Now all that stands between me and my goal is a dozen ticks or so.

You could make the off-switch in the nether instead of in the overworld.

I finally found and fixed the issue. It will be available soon (tm).

It's also possible to bug the dispenser state causing water to become stuck that later will cease to exist if you try to pick it up with a bucket manually, but can never be picked up by the dispenser + empty bucket until it is cleared.

Yes, I noticed that. My fix could also fix that issue with dispensers and droppers. I didn't do extensive testing on those to see that this was the actual problem in your machine, but they did have the same problems as pressure plates.

Regarding the works as intended, there is still the matter of this device operating completely different with two players than it does with 1. I don't dispute that unloaded chunks shouldn't tick. I dispute the necessity of unloading a chunk that has active Redstone circuitry ticking. Just keep the chunk in memory a few more ticks until it goes idle, and then release it. That would make the behavior consistent between single player and multi player and allow me to finish building a safe room.

That is indeed a problem depending on what you want to do, but it's not a bug. We have for a very long time discussed how we want redstone to work in regards of unloaded chunks, but so far we haven't come to a conclusion. Having all redstone machines keep chunks loaded could result in performance degradation. In your scenario there are many things one needs to choose: How many chunks should be kept loaded? For how long? Should only redstone tick or should everything else as well (fire spreading, water flowing, mobs running around attacking, etc)? Some might use a portal as a "safe room" from when shit hits the fan, if we keep ticking their chunks it might ruin their worlds... Maybe that's a bit far fetched, but it could happen.

While it looks like the same bug, this is actually at least two bugs squashed into a single ticket.

I have just made a fix that fixes: Pressure plate, tripwire, redstone lamp, detector rail, buttons and probably dispensers and droppers as well. What separates these from some others in this ticket is that these would not get fixed by reloading the world. In fact, what was causing this issue was the actual saving of the world. Reloading wouldn't fix it since the saved state is broken.

Pistons however is a completely different chapter.

The blocks that should get fixed by my fix are: Pressure plate, tripwire, redstone lamp, detector rail and buttons.

I looked into this, and you're partially right and wrong.

Just as SuperGeniusZeb said it is correct, intended and designed for you to come back to the same portal you walked into. This is because when you changed dimension the chunk stopped ticking. When you go back the machine will continue ticking and thus disable the portal.

However, the bug that you mentioned in the previous comment did interest me so I tested this (thanks for the attached map!). Some redstone components (in this case it seems to be affecting the pressure plates) isn't serialized correctly. When you get back to the chunk the pressure plates might be locked in a "pressed" state. You have to rebuild them to get it working again. I'm working on a fix for this right now.

Even though the pressure plates and various other things are broken, the bug that you describe in the bug description is actually working as intended.